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respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport System (ITS). 
The present document is part 1 of a multi-part deliverable covering the V2X application, as identified below: 

Part 1: "Road Hazard Signalling (RHS) application requirements specification"; 

Part 2: "Intersection ColUsion Risk Warning (ICRW) application requirements specification"; 

Part 3: "Longitudinal Collision Risk Warning (LCRW) application requirements specification". 



Introduction 



ITS stations (ITS-Ss) are exchanging information with each other to satisfy a large diversity of customers' services. 

With the purpose to scope the standardization work, a basic set of applications (BSA) [i.l] has been published. Driven 
by European safety and traffic management ITS directive and within the scope of the European Mandate M/453 [i.5] a 
subset of the BSA application requirements specifications, dedicated to road safety, has been proposed. 

The present document covers the application requirements specification related to Road Hazard Signalling (RHS) 
application. 

RHS application is distributed in conforming vehicles. Two different functional modes of the application are defined in 
the present document: 

• The originating mode considers the detection and signalling of a road hazard from an ITS-S to other ITS-Ss. 
This functional mode triggers the generation of DENMs relevant to considered use cases according to their 
specific requirements. As CAM and DENM may address different road safety application performance 
requirements, at least two performance classes (A and B) are considered in the present document. 

• The receiving mode considers the signalling of road hazards to the driver of the receiving vehicle when 
relevant to him. This signalling is an information which is given (driver awareness) by the receiving ITS-S to 
the driver and which does not require an immediate action. The objective of this application is to increase its 
vigilance. For such an application, the performance requirements are less strict than for collision avoidance 
and a class B performance is acceptable. 
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Scope 



The present document provides the specification of the ITS application Road Hazard Signalling (RHS) based on the 
cooperative awareness (CA) basic service [1] and the decentralized environmental notification (DEN) basic service [2]. 
This includes functional and operational requirements of the RHS application for other layers and entities of an 
ITS-Station on both the originating and the receiving sides. 

For the originating side of the RHS application the operational conditions related to the hazard detection and the 
triggering of the DENM are specified. Furthermore values are defined for use case specific data elements of the DENM 
and for indication of a message priority to achieve the required timely transmission. 

In addition the present document considers performance requirements for the generation and transmission of the CAM 
and DENM, which enable different levels of RHS, and also collision avoidance and collision mitigation applications. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vaUd at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 302 637-2 (VI. 3.0): "Intelligent Transport Systems (ITS); Vehicular Communications; 

Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service". 

[2] ETSI EN 302 637-3 (VI. 2.0): "Intelligent Transport Systems (ITS); Vehicular- Communications; 

Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification 
Basic Service". 

[3] CEN EN 16072 (201 1): "Intelligent Transport Systems - eSafety - Pan European eCall operating 

requirements". 

[4] CEN EN 15722 (2001 1): "Intelligent Transport Systems-eSafety - eCall minimum set of 

data (MSD)". 

[5] ISO 3779: "Road vehicles — Vehicle identification number (VIN) — Content and structure". 

[6] ETSI TS 102 724: "Intelligent Transport Systems (ITS); Harmonized Channel Specifications for 

Intelligent Transport Systems operating in the 5 GHz frequency band". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 102 638: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of 

Applications; Definitions". 

[i.2] ETSI TS 101 539-2: "Intelligent Transport System (ITS); V2X appHcation; Part 2: hitersection 

Collision Risk Warning (ICRW) application requirements specification". 
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[i.3] ETSI TS 101 539-3: "Intelligent Transport System (ITS); V2X application; Part 3: Longitudinal 

Collision Risk Warning (LCRW) application requirements specification". 

[i.4] ISO 17425: "Data exchange specification for in-vehicle presentation of external road and traffic 

related data ("embedded VMS")". 

[i.5] Mandate M/453: Co-operative systems for Intelligent Transport in the field of information and 

communication technologies to support interoperability of cooperative systems for intelligent 
transport in the European Community. 

[i.6] Draft ISO TS 21219-15 (201 1-1 1): "IntelHgent transport systems - Traffic and Travel Information 

via Transport Protocol Experts Group, generation 2 (TPEG2) — Part 15: Traffic Event Compact 
(TPEG2-TEC)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

age of data: difference between the time of a data element value setting at the originating ITS-S and the time the same 
data element value is used to undertake an appropriate action at a receiving ITS-S level 

NOTE: The age of data is an important quality parameter reflecting the freshness of higly dynamic data elements 
in particular when a collision risk is assessed at vehicles' receiving levels. 

criticality of the traffic safety situation: indicator of the traffic situation with regard to the TTC (Time To Collision) 
and the time required to act avoiding or mitigating a collision 

eCall back-up: function which sends a manual (back-up) eCall on behalf of the vehicle being in an accident and not 
able to send out an (primary) eCall by itself due to telecommunication problems [3] 

ego vehicle: vehicle embedding the ITS-S being considered 

primary road safety application: application which purpose is to avoid a collision 

NOTE: Several means are possible from giving some information to the driver to acting directly on the vehicle. 
Secondary and tertiary safety applications do not avoid collision; They respectively can mitigate the 
collision (pre-crash, post crash) or accelerate the emergency rescue. 

service primitive: element of a service request being sent from the application to some facilities layer function, e.g. to 
the CA / DEN basic service 

NOTE: The service primitive not only requests a particular action but also provides the transfer of data elements 
and parameters values. 

Subject Vehicle (SV): vehicle equipped with the Road Hazard Signalling application for which a signalled road hazard 
awareness indication will be provided to the driver 

Target Vehicle (TV): vehicle equipped with the Road Hazard Signalling application which detects and signals a road 
hazard to other vehicles moving locally and which is susceptible to be involved in a collision with the subject vehicle 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

BSA Basic Set of Applications 

CA Cooperative Awareness 

CAM Co-operative Awareness Message 

CAN Controller Area Network 

CCH Control Channel 
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CNG Compressed Natural Gas 

DCC Decentralized Congestion Control 

DEN Decentralized Environmental Notification 

DENM DEN Message 

DSRC Direct Short Range Communication 

EMI Electro Magnetic Interference 

G5A Frequency band between 5,875 GHz and 5,905 GHz 

GPS Global Positioning System 

GST Global System for Telematics 

HMI Human Machine Interface 

ICRW Intersection Collision Risk Warning 

ITS Intelligent Transportation System 

ITS-S ITS Station 

IVS In- Vehicle Signage 

LCRW Longitudinal Collision Risk Warning 

LDM Local Dynamic Map 

LPG Liquid Propane Gas 

MAT Maximum Action Time 

MDRT Maximum Driver Reaction Time 

MLT Maximum Latency Time 

MSD Minimum Set of Data 

OEM Original Equipment Manufacturer 

OR Operational Requirement 

PER Packet Error Rate 

PSAP Public Safety Access Point 

RHS Road Hazard Signalling 

TPEG Transport Protocol Expert Group 

TTC Time To Collision 

V2X Vehicle to any type of other station 

VDS Vehicle Type Descriptor 

VIN Vehicle Identification Number 

VMS Variable Message Sign 

WMI Worldwide Manufacturer Index 



4 Originating ITS-S performance class definition 

Primary road safety applications have different purposes from providing information about road hazard to acting 
directly on the vehicle to avoid a collision. The complete system performance can be divided into three parts: 

• The ITS-S originating part which provides dynamic data elements being used by receiving vehicles to assess 
the level of collision risk. 

• The wireless network performance which is variable according to network characteristics, radio obstacles and 
network load. 

• The ITS-S receiving part whose performance can be adjusted according to the applications which are 
supported by the local ITS-S. 

An originating ITS-S is then serving several categories of applications (see figure 4. 1) without knowing which ones are 
implemented at the level of receiving ITS-S. Standards being currently developed by ETSI TC ITS WGl and 
CEN TC 278 WG16 in the scope of the M/453 mandate [i.5] are positioned according to figure 4.L 
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Figure 4.1 : Applications being served by transmission 

NOTE 1 : Performance requirements for wireless network and ITS-S receiving part are out of the scope of the 
present document. 

NOTE 2: The given TTC values are just examples. 

These are several data services which contribute to the primary safety goal and increase driver awareness and collision 
avoidance capabilities, for example: 

• The "driver information" may be achieved by digital radio broadcast channels or cellular network using TPEG 
[i.6] or "In-Vehicle signage" (IVS) covering fixed or variable message sign information such as currently 
under specification by road operators [i.4]. 

• The "driver awareness" may be achieved with the RHS application upon reception of CAMs and DENMs. 

• The "driver warning" may be achieved with the ICRW [i.2] and the LCRW [i.3] applications upon reception of 
CAMs and DENMs from neighbouring ITS-Ss. 

One important quality parameter for receiving road safety applications is the knowledge of the "age" of data to enable 
the application in receiver to interpolate the received data values for a situation evaluation corresponding as close as 
possible to the real originating vehicle situation, e.g. trajectory, velocity. 

Consequently, whatever the application is considered, the quality of the offered customer service will be relying on the 
quality of available data at the receiving ITS-S level. 

The age of data at the receiving level is then depending on the distributed application end to end latency time such as 
defined on figure 4.2. 
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Figure 4.2: Age of the target vehicle data at consideration in the subject vehicle application 

For critical road safety application (collision avoidance) and for pre-crash application an estimated 300 ms end to end 
latency time seems to be required to avoid false decisions based on old data. 

At the receiving level, the age of data can be constantly calculated based on the time stamp difference (Time stamp at 
T5 - Time stamp at Tl) however, TO to Tl is not included in this calculation. 

For receiving application it is then required to be able to estimate the TO to Tl time to be added to the calculated 
T5 - Tl. For this purpose it has been decided to specify two ITS-S performance classes: 

• Class A which shall guarantee a TO to Tl time less than 150 ms. 

• Class B which does only guaranty a TO to Tl time less than 1,4 s. 

NOTE 3: TO to T lis the latency time required to present updated data from the vehicle electronics (sensors) at 
CAM and DENM basic service interface level. 

When an originating ITS-S is conforming to class A, this will be indicated in CAMs and DENMs (data quality 
parameter), so enabling the complete estimation of the age of received data elements (worst case age: T5 - Tl + 150 ms) 
during critical safety situation involving the ego vehicle. 



5 Road Hazard Signalling application description 

RHS application is an application layer entity of the ITS-S that triggers the transmission of messages such as DENM as 
specified in [2] and processes received messages in order to provide information on the road hazard to road user. 

The present document considers the ten following use cases of the RHS application corresponding to different types of 
road hazard situations. However this list is not exhaustive and can be extended in the future: 

1) Emergency vehicle approaching (clause 6.3.1). 

2) Slow vehicle (clause 6.3.2). 

3) Stationary vehicle (clause 6.3.3). 

4) Emergency electronic brake lights (clause 6.3.4). 

5) Wrong way driving (clause 6.3.5). 
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6) Adverse weather condition (clause 6.3.6). 

7) Hazardous location (clause 6.3.7). 

8) Traffic condition (clause 6.3.8). 

9) Roadwork (clause 6.3.9). 

10) Human presence on the road (clause 6.3. 10). 

NOTE: The present document does not imply any specific implementation of RHS application. In one possible 
implementation RHS may implement several use cases in one application layer entity, while in another 
possible implementation each use case may be implemented as one specific application layer entity. 

RHS application includes two instances implemented in the originating and in the receiving ITS-S respectively. 

At the originating ITS-S, the road hazards are detected by the RHS application and signalled to all vehicles moving in 
the relevance area through the triggering of the related DENMs transmission. 

The RHS application may provide specific CAM interval adjustment requests to the CA basic service (see informative 
annex F) in order to improve the confidence level at the receiving ITS-S side. 

The CAM transmission interval is adjusted by the CA basic service as specified in [1]. 

At the receiving ITS-S, the RHS application specific purpose is to allow to make the driver aware of a road hazard 
which may become the cause of an accident (see figure 4.1). In this situation, the driver attention is focused without 
requiring an immediate action to avoid an accident. 

5.1 Functions provided by the originating RHS application 

The main functions provided by the RHS application at the originating ITS-S level are: 

• Requesting of the DEN basic service for the execution of the considered road hazard signalling service when a 
road hazard is detected. This includes the provision of the service requests/primitives generic and specific to 
each use case to the DEN basic service as specified in [2] with the objective to handle the transmission of 
necessary DENMs in the defined relevance area according to well specified functional and operational 
conditions. Some generic and use case specific data elements are also provided by the RHS application to the 
DEN basic service during the service requests. 

• If conforming to performance class A, the detection of a critical traffic safety situation implies the setting-up 
of a relevant priority level accordingly. Table 5.1.1 provides the priority level being assigned according to the 
criticality level of the traffic safety situation, which is defined by the time to a potential collision as presented 
in figure 4. 1 . 

Table 5.1.1: Priority levels 



Criticality of the traffic safety situation 


Priority level 


Driver awareness situation 


2 


Warning situation (Driver assistance or automatic action) 


1 


Pre-crash situation 






The priority level shall be communicated to facilities (messages management), communication, DCC and security 
functions in order to achieve their contribution to the data quality (freshness/age of the data elements) required for 
performance class A especially during critical traffic safety situations. 

5.2 Functions provided by the receiving RHS application 

The main function provided by the RHS application at the receiving vehicle level is the notification of a road hazard to 
the driver based on the processing of received CAMs, DENMs or other messages. These messages can originate from 
Vehicle and Roadside ITS-Ss. 
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Each receiving ITS-S determines how to make use of the received messages according to its relative evolution with 
regard to the signalled road hazard and according to the quality of received data and/or data elements (e.g. accuracy, 
age, confidence level). 



6 Application functional requirements 

6.1 Application flow requirements 

The application protocol follows a state machine. An implementation example for Vehicle ITS-S is provided in 
annex B. 

The following functional requirements are defining the state machine: 

FRAOl: For a Vehicle ITS-S, the RHS application shall be active as long as the ITS-S is active. 

FRA02: For a Roadside ITS-S, the RHS application shall be started and terminated according to supported use cases 
and specific rules provided by the road operator in charge of its operation. 

FRA03: For a Vehicle ITS-S, as soon as the link to the facilities layer functions and other applications is established, 
the RHS application shall analyze own sensor data status information and road hazard information from other ITS-S to 
determine a need to assist the driver. 

FRA04: For a Roadside ITS-S as soon as the link to the facilities layer functions and other applications is established, 
the RHS application shall achieve the required operations according to supported use cases. 

FRA05: For a Vehicle ITS-S, the RHS application shall be capable of taking action (e.g. trigger driver information) of a 
valid and relevant road hazard based on received messages. The validity and relevance of the received road hazard 
signalling shall be established when the subject vehicle is positioned as being heading toward the road hazard and being 
at a given minimum distance of it. 

NOTE 1 : The minimum distance determination is left to the OEM decision as well as how the driver information 
will be actually presented. 

FRA06: If the RHS conforms to performance class A (see clause 7), it shall be capable to detect a critical traffic safety 
situation and shall be able to set the relevant priority level accordingly (see table 5.1.1). The relevant priority level 
being set shall be communicated to the facilities layer functions to be able to adjust the messages time interval and 
priorities. 

FRA07: For any ITS-S, as soon as a road hazard is detected, the RHS application shall request the DEN basic service to 
start the DENMs transmission. 

FRA08: All ITS-Ss implementing the RHS application shall have the capability to transmit DENMs to ITS-Ss being 
present in a specified relevance area (see operational requirements in clause 7 of the present document). 

NOTE 2: It is assumed here that the RHS application provides all necessary primitives and data elements to the 
DEN basic service to trigger the DENMs transmission. This means that in case of failure of the RHS 
application, the DEN basic service has all the elements to achieve its DENMs transmission mission 
completely. 

6.2 Dedicated channel in case of G5A access technology 

If the G5 A access technology is used to support the RHS application, the following functional requirement is 
apphcable: 

FRA09: The CAM and DENM shall be transmitted in an ITS G5A channel [6] assigned for road safety applications. 
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6.3 Functional requirements - originating vehicle 

This clause provides for the originating vehicle, first the functional requirements generic to all considered use cases and 
then functional requirements specific to each considered use case. 

FRAIO: RHS priority level assignment. 

By default the priority level shall be assigned the value "2". 

If the ITS-S conforms to performance class A, and another vehicle is detected as being in a critical traffic safety 
situation with the ego vehicle, the priority level shall be set to value " 1 " or "0" according to the detected situation 
(warning or pre-crash). 

FRAll: The following parameters, primitives and data elements being provided in tables 6.3.1, 6.3.2, 6.3.3 and 6.3.4 
shall be transferred to the DEN basic service through a service request initiated by any considered use case triggering 
condition: 

Table 6.3.1 : Quality parameters passed from the RHS application to the DEN basic service 



Quality parameters 


Parameter 


Description 


Mandatory (M) or Optional (0) 


Priority level (reflecting the criticality 
level of the traffic safety situation) 


• 2: If the ego vehicle is not in a 
critical safety situation. 

Only for performance class A: 

• 1: If a vehicle is in a warning 
situation to the ego vehicle. 

• 0: If a vehicle is in a pre-crash 
situation to the ego vehicle. 


M 


Positioning system type 


For Vehicle ITS-S the RHS application 
may request the DEN basic service [2] 
to provide the type of vehicle 
positioning system being used. 






FRA12: The rule for the DEN basic service to define the DENM interval is: 

• The first DENM shall transmitted immediately following an RHS service request. 

• If the priority level is set to or 1, the DENM shall be repeated or updated with a time period equal or less 
than 100 ms. 

• If the priority level is set to 2, the DENM can be repeated or updated with a time period between 100 ms and 
1 s (e.g. according to the load of the assigned safety channel). 

The relevance area parameters for use cases being provided to the DEN basic service are specified in table 6.3.2. 

Table 6.3.2: Relevance area parameters 



Relevance area parameters 


Parameters 


Description 


Mandatory (M) or Optional (0) 


RelevanceDistance 


Distance of relevance from the current 
position of the detected road hazard. 


M 


RelevancelrafficDirection 


Relevant traffic direction with regard to 
the current position of the detected 
road hazard. 


M 



The event termination condition(s) will be specified at use case level. 

The service primitive to be provided by the RHS application to the DEN basic service for the request of the DENM 
transmission termination is specified in table 6.3.3. It shall be provided when one event terminating condition is 
detected. 
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Table 6.3.3: Termination parameter 



DENM transmission Termination 


Primitive 


Description 


IVIandatory (IVI) or Optional (0) 


DENMTermination 


Stop the DENMs transmission 


M 



The interface between the RHS application and the DEN basic service of the facilities layer shall be as specified within 
[2]. The following data elements (identified in table 6.3.4) shall be provided for all use cases. These data elements shall 
be provided when one event triggering condition is detected and as soon as one of the data element value is updated e.g. 
expiry time. 

Table 6.3.4: Data element values to be provided at event triggering time 



Data Element: Detection Time 


Value 


Description 


Mandatory (M) or Optional (0) 


Time 


Time at which the hazard is detected. 


M 


Data Element: Expiry Time 


Value 


Description 


Mandatory (M) or Optional (0) 


Time period or N/A* according to use 
case. 


The estimated maximum time duration 
of the hazard. 


M 


Data Element: Information Quality 


Value 


Description 


Mandatory (M) or Optional (0) 


Quality level 


Quality of the provided information 


M 


Data Element: Event Position 


Value 


Description 


Mandatory (M) or Optional (0) 


Longitude, Latitude, Altitude values of 
the hazard position. 


Position of the hazard mainly deduced 
from the position of the originating 
vehicle excepting for road work which 
is the position of the starting point of 
the work zone. 


M 


Data Element: Event Heading Direction 


Value 


Description 


Mandatory (M) or Optional (0) 


Current heading value or N/A*. 


Current heading of the vehicle 
signalling a road hazard. 


M 


Data Element: Event Heading Confidence 


Value 


Description 


Mandatory (M) or Optional (0) 


Current level of confidence in provided 
data or N/A*. 


Assessment of the confidence level to 
be placed on provided data. 


M 


Data Element: Trace ID 


Value 


Description 


Mandatory (M) or Optional (0) 


Trace identifier value or N/A*. 


Provides the trace ID enabling the 
provision of several traces. 


M 


Data Element: Trace 


Value 


Description 


Mandatory (M) or Optional (0) 


Set of way point values or N/A* 


Indication of the path followed by the 
vehicle before signalling the hazard. 


M 


*N/A: Not Applicable 



The relevance area is determined by the DEN basic service according to event position, heading direction and trace data 
elements. In particular, the trace will be used in reception for fine tuning the triggering of the driver awareness 
notification, while the relevance area is more for the determination of the geographical area in which DENMs shall be 
propagated. 

6.3.1 Emergency vehicle approaching specific functional requirements 

FRUClOl: When a Vehicle ITS-S is operating an emergency mission [i.6], the RHS application shall request the DEN 
basic service to trigger the transmission of "approaching emergency vehicle indication" DENMs in the relevance area 
defined according to its trajectory. 

NOTE 1: An approaching emergency vehicle may also be detected through received CAMs. In such case the 
application is expected to have the same functional requirements. 
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FRUC102: Event triggering conditions. 

DENM transmission shall be triggered manually or automatically. 

FRUC103: Specific Vehicle ITS-S states and conditions. 

None. 

FRUC104: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and a direction of the emergency 
vehicle approaching event. 

The relevance area should be as far as possible determined by the RHS application according to the path prediction of 
the emergency vehicle. 

NOTE 2: The path prediction data element can be deduced from the programmed itinerary of the emergency 
vehicle if this one is available. 

NOTE 3: The relevance distance and the relevance direction is as specified in [2]. 

FRUC105: Event termination condition(s). 

The RHS application shall terminate the DENM transmission as soon as the emergency vehicle stops its emergency 
mission (manual or automatic stop). 

FRUC106: Use case specific data element values to be provided. 

The following data element values (table 6.3.5) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.5: Specific use case data elements 



Data Element 1 .1 : Cause Code 


Value 


Description 


Mandatory (Wl) or Optional (0) 


RHS_CauseCode 


Emergency vehicle approaching as 
specified in [2]. 


M 


Data Element 1 .2: Sub Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode 


One of the sub cause code as 
specified in [2] clause 7.1.3. 





Data Element 1 .3: Event Speed 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_EventSpeed 


Current speed of the emergency 
vehicle. 


M 


Data Element 1 .4: Vehicle Type 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS Vehiclelype 


One of [i.6] tec 11 5. 


M 


Data Element 1 .5: Path Prediction 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS Trace 


Set of planned way points 






6.3.2 Slow vehicle specific functional requirements 

FRUC201: A slow Vehicle ITS-S shall request the DEN basic service to trigger the transmission of "slow vehicle 
indication" DENMs in the relevance area defined according to its trajectory. 

FRUC202: Event triggering conditions. 

The event shall be triggered automatically if a vehicle, whatever its type is, is moving slowly and constantly 
significantly slower than the average speed of the surrounding traffic. 

NOTE 1 : It is up to the vehicle manufacturer to define more precisely the conditions leading to the start and stop of 
the slow vehicle indication DENMs, e.g. it can be either according to the vehicle type, or according to 
some vehicle problems or to a particular vehicle mission. 
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FRUC203: Specific Vehicle ITS-S states and conditions. 

None . 

FRUC204: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and the direction of the slow 
vehicle. 

The relevance area should be as far as possible determined according to the topology and regulatory speed limit 
applicable on the road according to the path prediction of the slow vehicle. 

NOTE 2: The path prediction data element can be deduced from the programmed itinerary of the slow vehicle if 
this one is available. 

NOTE 3: The relevance distance and the relevance direction is as specified in [2]. 

FRUC205: Event termination condition(s). 

If the speed difference of the vehicle and the traffic flow is lower than a given speed difference for a predetermined 
period of time the event shall be terminated. 

NOTE 4: The definition of the speed difference and time period is up to the vehicle manufacturer or equipment 
supplier for vehicles being equipped in after sales. 

FRUC206: Use case specific data element values to be provided. 

The following data element values (table 6.3.6) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.6: Specific use case data elements 



Data Element 2.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


Slow vehicle indication as specified in 
[2] clause 7.1.3. 


M 


Data Element 2.2: Sub Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode 


One of the sub cause code as 
specified in [2], clause 7.1.3. 





Data Element 2.3: Event Speed 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS EventSpeed 


Current speed of the slow vehicle 


M 


Data Element 2.4: Vehicle Type 


Value 


Description 


Mandatory (M) or Optional (0) 


RH VehicleType 


One of [i.6] ted 26 


M 


Data Element 2.5: Path Prediction 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS Trace 


Set of way points. 






6.3.3 Stationary vehicle specific functional requirements 

FRUC301: A stationary vehicle shall request the DEN basic service to trigger the transmission of "stationary vehicle" 
DENMs in the defined relevance area. 

FRUC302: Event triggering conditions. 

The RHS application shall request the DEN basic service to transmit DENMs if at least one of the following event 
triggering condition is met: 

• Vehicle driver or passenger in an emergency situation requiring to stop immediately the vehicle. 
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NOTE 1 : A person in an "emergency situation" can be detected by means of portable medical monitoring 

equipment, e.g. glycaemia, heart attack, driver abnormal hypo vigilance monitoring system. In such case, 
the triggering of DENM transmission may be automatically activated by the medical monitoring 
equipment. 

• Vehicle problem (breakdown) requiring some technical support. 

• Vehicle in accident. The event triggering conditions are specified in [3]. 
NOTE 2: [3] defines the triggering conditions of eCall system. 

• Stationary vehicle with hazard lights on. 

• Public Transport vehicle at a Public Transport stop. 

FRUC303: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and the direction of the 
stationary vehicle event, e.g. from its path history. 

The relevance area should be as far as possible determined according to the topology and regulatory speed limit 
applicable on the road in which the stationary vehicle is positioned. 

NOTE 3: The relevance distance and the direction is as specified in [2]. 

FRUC304: Event termination condition(s). 

Transmission of DENMs shall stop if at least one of the following conditions apply: 

• The vehicle is moving again. 

• Upon receiving a negation DENM from a third party. 

FRUC305: Use case specific data element values to be provided. 

The following data element values (table 6.3.7) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.7: Specific use case data elements 



Data Element 3.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


Stationary vehicle as specified in [2] 
clause 7.1.3. 


M 


Data Element 3.2: Sub Cause Code 


Value 


description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode 


One of the following types as specified 
in [2] clause 7.1.3. 

• Human problem 

• Vehicle breakdown 

• Post crash 

• Post crash and carrying 
dangerous goods. 

• Public Transport stop 

• Unknown 


M 


Data Element 3.3 : Cause Extension 1 
(only applicable for RHS SubCauseCode "Human Problem") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseExtension 


One of the following type: 

• Glycaemia problem. 

• Heart problem. 

• Unknown. 
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Data Element 3.4: Cause Extension 2 
(only applicable for RHS SubCauseCode "Vehicle Breakdown") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseExtension 


One of the following types: 

• Lack of fuel 

• Lack of battery 

• Engine problem 

• Transmission problem 

• Engine cooling problem 

• Braking system problem 

• Steering problem 

• Tyre puncture 

• Unknown problem. 





Data Element 3.5: Cause Extension 3 
(only applicable for RHS SubCauseCode "Post Crash" and "Post crash and carrying dangerous goods") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCodeExtension 


One of the following types: 

• Accident without eCall 
triggered. 

• Accident with eCall manually 
triggered. 

• Accident with eCall 
automatically triggered. 





Data Element 3.6: Cause Extension 4 
(only applicable for RHS CauseCode "Post Crash and carrying dangerous goods") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_DangerousGoodData 


All to 
be pr 


Ilowing data elements values shall 
ovided: 

> Class. 

> Division. 

> UnNumber. 

> Emergency Action Code. 

> Phone Number. 

> Company Name. 

> Elevated Temperature. 

> Tunnels Restricted. 

> Limited Quantity. 





Data Element 3.7: Number of Occupants 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS NumberOf Occupants 


Estimated number of occupants. 





Data Element 3.8: Vehicle Type 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_VehicleType 


One of the vehicle type according to 
[1.6] tec 009. 


M 


Data Element 3.9: Vehicle Identification 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_Vehicleldentification 


Anonymous part of the VIN according 
to ISO 3779 [5]: 

• World IVIanufacturer Index 
(WMI). 

• Vehicle type descriptor (VDS). 





Data Element 3.10: Vehicle Storage Type 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_VehicleStorageType 


One of the following types: 

• Unknown. 

• Hydrogen storage. 

• Electric energy storage (with 
more than 42 V and 1 00 Ah). 

• Liquid Propane Gas (LPG). 

• Compressed Natural Gas 
(CNG). 

• Diesel tank present. 

• Gasoline tank present. 
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FRU306: Risk of explosion. 

If the accident leads to high energy storage loss detection (risk of explosion) the type shall be automatically extended 
with "accident with high energy storage loss detected (risk of explosion)". 

6.3.4 Emergency electronic brake lights specific functional requirements 

FRUC401: Event triggering conditions. 

A Vehicle ITS-S shall transmit an "emergency electronic brake lights" DENM in the defined area if one of the 
following conditions is met: 

• The emergency brake lights are set "on" and the deceleration value is equal or higher than a predefined 
"emergency braking deceleration" value. 

• The emergency brake lights are set "on" whenever the deceleration value is exceeded with or without the 
triggering of the warning by the vehicle driver. 

NOTE 1 : The assignment of the emergency braking deceleration value is left under the responsibility of the vehicle 
manufacturer or equipment supplier in case of in-vehicle services (after sales solution). 

FRUC402: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and a direction of the emergency 
electronic brake lights event. 

The relevance area should be as far as possible determined by the RHS application according to the path prediction of 
the vehicle originating the emergency electronic brake lights event. 

NOTE 2: The path prediction data element can be deduced from the programmed itinerary of the originating 
vehicle if this one is available. 

NOTE 3: The relevance distance and the relevance direction is as specified in [2]. 

FRUC403: Event termination conditions: 

• The emergency brake lights are set "Off". 

• The deceleration value is less than the predefined value. 

FRUC404: Use case specific data element values to be provided. 

The following data element values (table 6.3.8) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.8: Specific use case data elements 



Data Element 4.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


Emergency Electronic Brake Lights as 
specified in [2], clause 7.1.3. 


M 


Data Element 4.2: Sub Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode 


One of the sub cause code as 
specified in [2], clause 7.1.3. 





Data Element 4.3: Event Speed 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_EventSpeed 


Speed of the hard braking vehicle 
when the event is detected. 


M 
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6.3.5 Wrong way driving specific functional requirements 

FRUC501: A vehicle moving against the regular traffic flow shall detect countersense driving if equipped with the 
necessary capabilities and disseminate "wrong way driving indication". Any other ITS-S detecting a vehicle moving 
against the regular traffic flow shall disseminate "wrong way driving indication" to Vehicle ITS-Ss. 

FRUC502: Event triggering conditions. 

The RHS shall trigger the transmission of "wrong way driving" DENMs if the trajectory followed by a vehicle is 
detected to be in countersense of the regulated vehicles flow. This may be achieved using an application associated to a 
global digital map or using a local digital map. 

FRUC503: Relevance area. 

The RHS application of the originating ITS-S shall define at least the relevance distance and the relevance direction of 
the wrong way driving event. 

The relevance area should be as far as possible determined according to the road topology in which the wrong way 
vehicle driving is evolving. 

NOTE 1 : The relevance distance and the relevance direction are as specified in [2] . 

FRUC504: Event termination conditions. 

The RHS application shall terminate the transmission of DENMs if at least one of the following conditions is met: 

• The vehicle is no longer moving countersense. 

• The vehicle is stationary with its engine stopped. 

NOTE 2: The second condition may trigger the "stationary vehicle" indication. 

FRUC505: Use case specific data element values to be provided. 

The following data element values (table 6.3.9) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.9: Specific use case data elements 



Data Element 5.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


Wrong way driving as specified in [2], 
clause 7.1.3. 


M 


Data Element 5.2: Sub Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode 


One of the sub cause code as 
specified in [2], clause 7.1.3. 





Data Element 5.3: Event Speed 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_EventSpeecl 


Current speed of the wrong way 
driving vehicle. 


M 



6.3.6 Adverse weatlier condition specific functional requirements 

FRUC601: A Vehicle ITS-S or a Roadside ITS-S equipped with the required capabilities to detect one or several 
adverse weather condition(s) shall transmit DENMs if at least one of the following adverse conditions defined in 
table 6.3.10 is detected. 

FRUC602: Event triggering conditionL: 

• Beginning of a low visibility area for example caused by fog, smoke, heavy rain or snow. 

• Ending of a low visibility area. 
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• Beginning of a low stability area for example caused by ice, snow, oil or wind. 

• Ending of a low stability area. 

NOTE 1 : The solution developed for the detection of the beginning or ending of a particular weather condition is 
left at the discretion of vehicle manufacturers and road side units suppliers. 

FRUC603: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and a direction of the adverse 
weather condition event. 

The relevance area should be as far as possible determined by the RHS application according to the road topology in 
which the vehicle which detects the adverse weather condition is evolving. 

NOTE 2: The relevance distance and the relevance direction are as specified in [2]. 

FRUC604: Event termination condition: 

• From the originating ITS-S, automatically after the transmission of at least one DENM. 

NOTE 3: According to the used access technology, several DENMs could be sent by lower layers in order to ensure 
that at least one is properly received. 

FRUC605: Use case specific data element values to be provided. 

The following data element values (table 6.3.10) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.10: Specific use case data elements 



Data Element 6.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


One of the following weather 
conditions specified in [2], clause 
7.1.3: 

• Precipitation. 

• Extreme weather condition. 

• Adhesion. 

• Visibility. 


M 


Data Element 6.2: Sub Cause Code as specified in [2 


, clause 7.1.3. 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode for adverse 
weather condition "Precipitation". 


One of the type in [i.6], tec 1 1 9. 


M 


RHS_ SubCauseCode for adverse 
weather condition "Extreme Weather 
Condition". 


One of the type in [i.6], tec 106. 


M 


RHS_SubCauseCode for adverse 
weather condition "Adhesion". 


One of the type in [i.6], tec 106. 


M 


RHS_SubCauseCode for adverse 
weather condition "Visibility". 


One of the type in [i.6], tec 1 1 8. 


M 


Data Element 6.3: Cause Extension 1 
(applicable only for sub cause "Precipitation") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS CauseExtension 


One of the type in [i.6], tec 11 9. 


M 


Data Element 6.4: Cause Extension 2 
(applicable only for sub cause "Wind") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS CauseExtension 


One of the type in [i.6], tec 106. 


M 


Data Element 6.5: Cause Extension 3 
(applicable only for sub cause "Adhesion") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS CauseExtension 


One of the type in [i.6], tec 106. 


M 
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Data Element 6.6: Cause extension 4 
(applicable only for sub cause "Visibility") 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS CauseExtension 


One of the type in [i.6], tec 11 8. 


M 


Data Element 6.7: External Temperature 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_ExternalTemperature 


Measured in ° C witli a granularity of 1 
degree. 






6.3.7 Hazardous location specific functional requirements 

FRUC701: A Vehicle ITS-S or a Roadside ITS-S detecting and locating a hazardous location shall signal it to other 
Vehicle ITS-Ss. Optionally a hazardous location signalling can be manually triggered by a person if the ITS-S is 
equipped with the technical capability to do it. 

FRUC702: Event triggering conditions: 

• Hazardous location automatically detected by a vehicle ITS-S or a Roadside ITS-S. 

• Optionally hazardous location detected by a person with the information provided manually to the ITS-S. 

FRUC703: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and a direction of the hazardous 
location event. 

The relevance area should be as far as possible determined according to the road topology in which the hazardous 
location has been positioned. 

NOTE I: The relevance distance and the relevance direction is as specified in [2]. 

FRUC704: Event termination condition: 

• After the transmission of at least one DENM from the originating Vehicle ITS-S. 

NOTE 2: According to the used access technology, several DENMs could be sent by lower layers in order to ensure 
that at least one is properly received. 

FRUC705: Use case specific data element values to be provided. 

The following data element values (table 6.3.1 1) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 
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Table 6.3.1 1 : Specific use case data elements 



Data Element 7.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


One of the following as specified in [2], 
clause 7.1.3. 

• Dangerous curve. 

• Surface condition. 

• Obstacle on the road. 

• Animal on the road. 


M 


Data Element 7.2: Sub Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubcauseCode for dangerous 
curve 


One of the following: 

• Unknown curve direction. 

• Dangerous left turn curve 

• Dangerous right turn curve 

• IVIultiple curves with unknown 
turning direction. 

• IVIultiple curves starting with left 
turn. 

• Multiple curve starting with right 
turn. 


M 


RHS_SubCauseCode for surface 
condition 


Surface condition [i.6], tec 109 


M 


RHS_SubCauseCode for obstacle on 
the road 


Obstacle on the road [i.6], tec 110 


M 


RHS_SubCauseCode for animal on 
the road 


Animal on the road [1.6], tec 1 1 1 


M 



6.3.8 Traffic condition specific functional requirements 

FRUC801: An evolution of the traffic condition and traffic jam shall be signalled by an ITS-S which has implemented 
this use case. The following traffic conditions shall be considered: 

• Traffic jam in formation. 

• Stationary traffic. 

• Traffic j am ending. 

FRUC 802: Specific Vehicle ITS-S states and conditions. 

During a consolidated traffic jam, a vehicle could have a stopped engine for fuel economy and environmental 
protection. In such case, the Vehicle ITS-S shall continue to send periodically some DENMs even if the engine is 
stopped. 

FRUC803: Event triggering conditions: 

• Detection of a traffic jam formation through some consecutive emergency or strong brakes. 

• Detection of a stationary traffic jam through the vehicle being stationary during a predefined time, surrounded 
by other vehicles. 

• Detection of a traffic jam ending through some consecutive accelerations followed by stable normal speeds. 

The Vehicle ITS-S shall distinguish a stationary condition due to a traffic jam from any other normal, e.g. stop at a 
traffic lights or abnormal immobilization such as breakdown or post crash. 

FRUC804: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and a direction for signalled 
traffic condition event. 
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The relevance area should be as far as possible determined according to the topology and regulatory speed limit of the 
road in which the signalled traffic event is located. 

NOTE 1 : The relevance distance and the relevance direction are as specified in [2] . 

FRUC805: Event termination conditions: 

• At least one DENM shall be sent when detecting a traffic condition evolution. So, the terminating condition is 
automatically given by this rule. 

• At least one DENM shall be sent when detecting a stationary traffic. So, the terminating condition is 
automatically given by this rule. 

NOTE 2: In case of a stationary traffic due to a traffic jam, the periodic repetition of DENMs is left at the discretion 
of the implementation of the ITS-S, e.g. vehicle manufacturer. 

NOTE 3: According to the used access technology, several DENMs could be sent by lower layers in order to ensure 
that at least one is properly received. 

FRUC806: Use case specific data element values to be provided. 

The following data element values (table 6.3.12) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 



Table 6.3.12: Specific use case data elements 



Data Element 8.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


Traffic condition as specified in [2], clause 
7.1.3 


M 


Data Element 8.2: Sub Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode 


One of the following as specified in [2], 
clause 7.1.3 

• Traffic jam slowly increasing. 

• Traffic jam increasing. 

• Traffic jam strongly increasing. 

• Traffic stationary. 

• Traffic jam slightly decreasing. 

• Traffic jam decreasing. 

• Traffic jam strongly decreasing. 

• Unknown. 


M 


Data Element 8.3: Event Speed 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_EventSpeed 


Moving speed of the traffic jam endpoint 






6.3.9 Roadwork specific functional requirements 

FRUC901: Priority level assignment. 

The default priority level value "2" shall be kept. 

FRUC902: Event triggering condition. 

The road operator of a vehicle ITS-S or of a Roadside ITS-S signalling a roadwork shall define the triggering conditions 
for the transmission of DENMs according to the roadwork activity planed. 

FRUC903: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and a direction to the roadwork 
location. 
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The road operator of a Vehicle ITS-S or of a Roadside ITS-S signalling a roadwork shall define the relevance area in 
which the roadwork information shall be disseminated according to the road topology and regulatory speed limits. 

NOTE: The relevance distance and the relevance direction are as specified in [2]. 

FRUC904: Event termination condition(s). 

The termination conditions for the broadcasting of the DENMs shall be determined by the road operator or of a Vehicle 
ITS-S or of a Roadside ITS-S signalling a roadwork according to the roadwork activity plan. 

FRUC905: Use case specific data element values to be provided. 

The following data element values (table 6.3.13) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.13: Specific use case data elements 



Data Element 91 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_CauseCode 


Roadworl< as specified in [2], clause 
7.1.3 


M 


Data Element 92: Sub Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_SubCauseCode 


According to [i.6], tec 103 and tec 105 
as specified in [2], clause 7.1 .3. 


M 


Data Element 93: Roadwork Segment Descriptor 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_RoadworkSegmentDescriptor 


Geographic position of the start of 
roadwork areas and the stop of 
roadwork area. 


M 


Data Element 94: Roadwork Closed Lanes 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_RoadworkClosed Lanes 


Total number of lanes, identification of 
closed lanes according to vehicles 
types [1.6], tec 009. 


M 


Data Element 95: Speed Limits 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_Speed Limits 


Regulatory speed limits per remaining 
open lane and according to vehicle 
types [1.6], tec 009. 


M 


Data Element 96: Authorized Vehicle Types 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_AutliorizedVeliicleTypes 


List of authorized vehicle types 
according to [1.6], tec 009. 





Data Element 97: Recommended Itinerary 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_Recommended Itinerary 


List of waypoints to re-access a road 
which is closed on a given segment. 






6.3.1 Human presence on the road specific functional requirements 

FRUClOOl: This use case shall only be used in road environment normally forbidden to pedestrians (e.g. motorways, 
express road, etc.) and when the ITS-S has the capability to properly detect this environment. Moreover, in case of a 
Vehicle ITS-S, the vehicle shall be stationary. 

FRUC1002: Event triggering condition: 

• Automatic triggering by the Vehicle ITS-S detecting that one of its occupants is leaving the vehicle. 

• Manually triggered by one of the passenger of the vehicle signalling its departure from the vehicle. 

• Manually triggered by the human himself using a capable nomadic device. 
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FRUC1003: Relevance area. 

The RHS application of the originating ITS-S shall define at least a relevance distance and a direction of the human on 
the road event. 

The relevance area should be as far as possible determined according to the topology and regulatory speed limits of the 
road in which the human presence is signalled. 

NOTE: The relevance distance and the relevance direction are as specified in [2]. 

FRUC1004: Event termination conditions: 

• Automatic triggering by the Vehicle ITS-S upon detecting either that all the occupants of the vehicle are 
returned inside or that the vehicle is moving again. 

• Manually triggered by one of the occupants of the vehicle signalling their return inside the vehicle. 

• Manually triggered by the human himself using a capable nomadic device. 

FRUC1005: Use case specific data element values to be provided. 

The following data element values (table 6.3.14) shall be provided by the RHS application to the DEN basic service 
when issuing the service request initiated upon identified event triggering conditions. 

Table 6.3.14: Specific use case data elements 



Data Element 10.1 : Cause Code 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS CauseCode 


People on the road. 


M 


Data Element 10.2: Triggering Condition 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS_TriggeringCondition 


One of the two following: 

• Manual 

• Automatic 


M 


Data element 10.3: Event Speed 


Value 


Description 


Mandatory (M) or Optional (0) 


RHS EventSpeed 


Moving speed of the human 






6.4 Generation of DENM negation from RHS application 

As identified in clause 6.3.3, when the stationary vehicle needs to be removed from the road by another vehicle, this 
situation is requiring a DENM negation to terminate the transmission of DENMs. This section specifies the DENM 
negation requests which are necessary to support the use cases being considered in the present document. 

6.4.1 Negation of stationary vehicle DENIVI 

FRUC311: A stationary vehicle will have to stop the dissemination of DENMs when removed by a third party from the 
road. Consequently, when the stationary vehicle is removed from the road, the stationary vehicle signalling shall be 
stopped by a third party ITS-S generating a negation DENM. 

NOTE: The signalling of a stationary vehicle can also be stopped by switching of its ITS-S or the Vehicle ITS-S 
detects acceleration and movement again. 

FRUC312: A capable third party ITS-S when being instructed to terminate a stationary vehicle signalling, e.g. 
consecutively to the removal of the vehicle from the road, shall send a DENM negation request to the DENM basic 
service of the facilities layer. 
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6.5 Functional requirements - Receiving vehicle 

As can be concluded from figure 4. 1, there is no binding between an application that is using the CAM and DENM 
basic services when signalling a detected road hazard and the actual application at the receiving ITS-S level that shall 
eventually have to undertake the appropriate action for the event in the subject vehicle, depending on the criticality of 
the traffic safety situation. 

This implies that the RHS application in the receiving ITS-S is simply analyzing received CAMs and DENMs to verify 
the relevance of received data elements with regard to its signalling purpose. These CAM and DENM shall be 
disseminated by as many as possible equipped vehicles being present in the relevant local area, with potentially 
different applications residing in receiving vehicles having to act according to their data elements' values. For example, 
in one subject vehicle, an ICRW application [i.2] will have to take the appropriate action and in a second subject 
vehicle, an LCRW application [3] will have to take an appropriate action and yet an a third subject vehicle, a RHS 
application will have to take the appropriate action. This leads to the following requirements in a receiving vehicle: 

FRROl: In the event of CAM and DENM reception, all capable ITS-Ss safety applications shall have access to all 
contained data elements being relevant to them. This includes that the ITS-Ss are able to receive and decode the various 
specific headers in the received messages as well as all data elements in associated containers being present in 
messages. The RHS application shall then process these data elements according to its purpose of triggering the 
signalling for driver awareness of a detected road hazard. 

FRROl: Received road hazard information shall be generating an action in the receiving vehicles if being judged 
relevant. This action is for example the notification of a "driver awareness indication" signalling the road hazard (cause 
and sub cause) being at the origin of the DENM. In this case, the way of presenting it to the driver and the presentation 
instant according to determined TTC is left at the discretion of the vehicle manufacturer or equipment supplier in case 
of an after sales installation. 



7 Application Operational requirements 

Road safety applications such as the RHS put some specific operational requirements on the whole ITS-S. As being 
introduced in clause 4 of the present document we distinguish two different performance classes (Class A and Class B) 
which not only enable the provision of premium RHS services but also satisfy some specific mandatory performance 
requirements associated to collision avoidance applications and pre-crash applications. 

This clause provides operational requirements which are applicable mainly to the RHS appUcation but also partly (Class 
A) to other road safety applications. 

NOTE: The RHS service definition and level of functions implemented is left to the vehicle 

manufacturers/equipment suppliers according to the quality of data elements being available at the 
receiving ITS-S side. 

7.1 Security and privacy -Class A and Class B requirements 

The following class A and class B common operational requirements (OR) shall be met: 

OROOl: The implemented ITS-S security solution shall not affect the interoperability and performance requirements 
which are defined for the normal operation of road safety applications. Particular attention shall be given at the level of 
the CAM and DENM transmission for class A and class B minimum performance requirements (see clause 7.3). 

OR002: A security solution shall be defined to ensure the respect of users' privacy especially for use cases related to 
violation of the law by the driver. 

OR003: This RHS application as the other road safety applications shall have the highest level of priority in terms of 
processing, storage, communication resources use. Non road safety applications shall not have the possibility to 
consume processing, storage and communication resources which are necessary for the normal operation of the RHS 
application(s). 
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7.2 Class A ITS-S operational system requirements 
7.2.1 Class A system security and dependability requirements 

OR004A: Short term certificates (pseudonyms) shall not be changed when the RHS application detects a critical traffic 
safety situation identified through the setting-up of priority levels "0" or "1". 

OR005A: The security and dependability solutions at the ITS-S level shall consider the following abnormal conditions 
which may be caused by a failure of system elements or external attacks: 

The absence of formatting CAMs and DENMs by the facilities layer (fail silent mode) once started by the RHS 
application. 

The signalling of a road hazard which does not exist (fail jabbering mode). 

The formatting of false or erroneous CAMs and DENMs (fail jabbering mode). 

The absence of transmitting the required formatted CAMs and DENMs (fail silent mode). 

The transmission of CAMs and DENMs with an interval being not in the range of standard CAM and DENM 
periods (fail silent or fail jabbering mode). 

The transmission of DENMs without being triggered by an authorized application (fail jabbering mode). 

The absence of reception of CAMs and/or DENMs (fail silent mode). 

The abnormal silence (fail silent mode) of the RHS application not informing the driver of a signalled road 
hazard. 

An abnormal activity (fail jabbering mode) of the RHS application informing the driver about nonexistent road 
hazards. 

OR006A: In case of a detected abnormal behaviour of the ITS-S (including the RHS application), the detecting 
function shall switch the RHS application to an "off" state (fail safe), informing the driver of this application failure. 

7.3 Class A system minimum performance requirements 

For the RHS application, only the minimum performance of the originating ITS-S is taken into account for Class A 
system. 

Receiving ITS-Ss will base their behaviour on received data elements and their associated quality levels. If the data 
elements' quality levels are not sufficiently good, the receiving applications, according to their purpose, may ignore 
them (fault tolerance principle) in order to avoid the issue of false indication to the driver. 

CAM and DENM provide data elements with their associated levels of quality as well as the confidence levels which 
can be associated to these data elements. 

Highly dynamic data elements identified below are really providing the kinematics of vehicles as well as their 
trajectories and velocities. Any change in these highly dynamic data elements shall be reflected as soon as possible at 
receiving ITS-S road safety applications level for them to properly achieve their functions. 

Some examples of highly dynamic data elements are: 

• The current position of the vehicle. 

• The vehicle heading. 

• The trajectory curvature. 

• The accelerations/decelerations (longitudinal, lateral, vertical) of the vehicle. 

• The yaw rate. 



£75/ 



28 ETSI TS 101 539-1 VI. 1.1 (2013-08) 

• The steering wheel angle. 

• The lane change indication. 

The provision and collection of these highly dynamic data elements is asynchronous to the CAM generation. 
Consequently, new data element values may be available just after the transmission of a CAM. If there is no update of 
these data elements until the next CAM generation, these data elements are delayed at least by the minimum time 
interval (100 ms). 

With the current available technologies it is given and accepted that the "age" of the highly dynamic data is up to 
300 collision avoidance and pre-crash can be realized under the condition that the velocity of the involved vehicles is 
less than 130 km/h. 

To be able to reach this maximum "age" of 300 ms, the originating ITS-S shall respect the following minimum 
performance requirements during critical traffic safety situations and provided that the used access network is not in 
a congested situation: 

OR007A: The total latency time between TO and T2 (see figure 4.2) shall be less than 220 ms in 95 % of the cases 
during critical traffic safety situations and provided that the used access network is not in a congested situation. T2 is 
measured when the messages are transmitted over the air while TO is measured at the vehicle electronic sensors' level. 

OR008A: Taking into account that the CAMs and DENM s minimum time interval is around 100 ms, the latency time 
between TO and Tl (see figure 4.2) shall be less than 150 ms in 95 % of the cases during critical traffic safety situations 
and provided that the used access network is not in a congested situation. Tl value is set when the CAM or DENM is 
constructed before being transmitted. 

OR009A: Performance Class A ITS-S shall indicate in CAMs that the ITS-S is conforming to Class A. 

NOTE 1: Knowing that an originating ITS-S is conforming to performance Class A, all receiving ITS-S may be 
able to constantly estimate the "age" of received data elements (see figure 4.2). This is achieved by 
calculating the difference between the T5 time stamp and the Tl time stamp and then adding the worst 
case delay between TO and Tl (150 ms). If some messages have been lost, automatically this will be 
detected through a constant increase of the age of data being not refreshed due to the messages lost. 

OROIOA: The End to End (from TO to T6) latency time increase caused by some network problems will be minimized 
as much as possible. In case of ITS G5 use this means that no more than 5 % consecutive packets loss shall be observed 
when the ITS-Ss operate under line of sight conditions within minimum transmission range being required. 

OROllA: The intended communication range which is directly related to the transmission power adjustment shall be by 
default of at least 300 m. Before reducing the transmission power for e.g. congestion control or EMI mitigation, the 
DCC shall verify that the priority level of the RHS application is not "1" or "0" meaning that the vehicle is in a critical 
traffic safety situation. 

OR012A: The receiving ITS-S shall be capable of processing at least 5 000 received messages (CAMs and DENMs) 
per second. 

NOTE 2: This value is taking into account the current capabilities of Vehicle ITS-S embedded technology. 
However, this value may be increased in the future due to technological improvements. 

For G5 access network, current studies show that two main actions may be taken to reduce the congestion of a given 
frequency channel, e.g. the CCH which is used for the broadcast of CAM and DENM and to mitigate interference 
between G5 and the European DSRC (Toll collect system): 

• Increasing the time interval of CAMs and DENMs 

• Decreasing the transmission power. 

Such actions may impact severely the efficiency of road safety applications during critical traffic safety situations 
(warning or pre-crash situations). Consequently: 

OR013A: The message time interval shall only be increased if the RHS application is not in a priority level "1" or "0". 

OR014A: The transmission power shall only be reduced if the current velocity of the vehicle permits this and if the 
RHS application is not in a priority level "1" or "0". 
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7.4 Class B system minimum performance requirements 

OR015B: The CAMs and DENMs time intervals shall be set between 100 ms and 1 s. 

OR016B: The originating Vehicle ITS-S shall have a total latency time (from TO to T2) of less than 1,5 s. This takes 
into account a possible messages' interval of 1 second. 

OR017B: The receiving Vehicle ITS-S shall have a total latency time (T3 to T6) of less than 500 ms. 
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Annex A (informative): 

Driver awareness triggering and presentation 

A Vehicle ITS-S (receiving mode) detecting or receiving a road hazard information is expected to consolidate it before 
delivering it to the driver. This consolidation may be achieved through the successive reception of CAMs indicating the 
same vehicle state, e.g. an approaching emergency vehicle in action or multiple DENM receptions originating from 
various vehicles, e.g. adverse weather condition. 

A driver awareness is expected to be delivered only if the distance separating the subject vehicle from the road hazard is 
decreasing. This may be detected by comparing the relative position of the road hazard to the subject vehicle without a 
navigation system including a digital map (comparing their positions evolutions with GPS). In this case, the distance is 
measured in a straight line (as the crow flies). 

A driver awareness may not be delivered directly to the driver if several applications share the driver HMI. In such case 
an arbitration function located in the HMI support function has to identify which information or warning has to be 
provided in case of simultaneous requests originating from different applications. Several criteria may be used for this 
selection: 

Type of assistance (see clause 4, figure 4.1). 

Distance separating the subject vehicle from the road hazard. 

Speed of the subject vehicle relative to the road hazard. 

Confidence level in the received information. 

Required driver action. 

Consistency of simultaneous requests to the driver. 

Possibility to merge several requests into one consistent assistance advice. 
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Annex B (informative): 
Application state machine 

Figure B. 1 shows an example of state machine for the RHS application. 
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Figure B.1 : Example of RHS application state machine 

In originating side for the safety messages intervals management: 

(1-2): When a critical safety situation is detected (combination of variables such as the time proximity vector, the 
vehicle heading, the trajectory being followed, vehicles respective velocities, etc.). 

(2-1): When leaving a critical safety situation (no risk of collision any more). 

In originating side for signalling a road hazard: 

(1-2): When the RHS application detects a road hazard, the application requests the transmission of DENMs by 
the facilities layer according to the functional requirements of the considered use case. 



(2-1): The Facilities layer function sends an acknowledgement to the RHS application indicating that its request is 
being executed. 

In reception side: 

(1-2): Engine Ignition (ITS-S activated) for a Vehicle ITS-S. For a Roadside Unit ITS-S, the transition is effective 
upon power-on. 

(2-1): RHS application deactivation or fault condition. 

NOTE: The RHS application deactivation will be achieved according to specific use case requirements. An 
engine stop is not a condition to switch the state machine "Off since for some particular vehicles, 
e.g. electric vehicles or during some particular traffic phases the engine can be stopped (stop - start mode) 
but the application needs to stay active. 

(2-3): Subscriptions to required facilities functions (configuration) terminated. 

(3-2): Change subscription (or change configuration) request. 

(3-1): RHS application deactivation or fault condition. 

(3-4): Consolidation of driver awareness for a Vehicle ITS-S. Start of a DENM broadcasting for a 
Roadside ITS-S. 

(4-3): End of driver awareness for a Vehicle ITS-S. End of DENM broadcasting for Roadside Unit ITS-S. 

(4-1): RHS application deactivation or fault condition. 



ETSI 



32 



ETSI TS 101 539-1 VI. 1.1 (2013-08) 



Annex C (informative): 
Application interface 



Application interfaces are a matter of implementation. However, according to the development of hardware and 
software modules which could be supplied by different sources, it could become necessary to standardize some of the 
application interfaces. Consequently, this annex presents the main facilities functions which may be required for 
interfacing to the RHS application. 

An overview of the RHS application interfaces is provided in figure C.l. 
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Figure C.I : RHS application interfaces 

The navigation application is optional and may be used to provide a more accurate relevance area for the 
DENM dissemination according to the position of the vehicle. 

CAM and DENM Management will interface the Management & Security Access function for the signature of 
the transmitted messages and the authentication of received messages. 

The RHS application will also interface the Management & Security function to take part in the selection of 
the communication profile to be used and the inhibition and enabling of the pseudonym change. 

The RHS appUcation may directly receive CAMs and DENMs from the CAM & DENM Management. It may 
also optionally access the LDM Management if present to detect some road hazards requiring driver 
awareness. 

The HMI support may include some arbitration function in case of simultaneous driver assistance requests 
coming from different applications supported by the vehicle (see annex B). 
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Annex D (informative): 

Example of G5 based exchange profile supporting this 

application 

The interoperability test is expected to be based on the definition of well specified exchange profiles. To be 
interoperable, two or more ITS-S need to have at least one common or compatible exchange profile. 

As represented in figure D.l, an exchange profile will be constituted of one particular communication profile associated 
to one particular application profile associated to one particular management and security profile. Figure D.l is taking 
as example the associated communication, application and management and security profiles which are the basis of the 
European project DRIVE C2X for road safety applications. This exchange profile has been the object of the first ETSI 
C-ITS plug test in Helmond during November 201 1 (not including the management and security profile). 
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Figure D.l : Example of an exchange profile 
based on G5A used for road safety applications 
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Annex E (informative): 

Virtual safety shield concept and TTC calculation 

The virtual safety shield concept consists to delimitate a virtual area surrounding the considered vehicle in such a way 
that when another vehicle enters this virtual area a particular attention will be paid to avoid a collision and thus 
protecting the vehicle occupants. This area may be shaped according to various parameters such as the respective 
vehicles' speeds or the road topology according to the data which are locally available (see figure E.l). 
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Figure E.l : Concept of virtual safety shiield 

A road safety application may constantly monitor the Time Proximity vectors which are separating the considered 
vehicle from all other vehicles which are surrounding it. This can be achieved by measuring the straight line distance 
between the vehicles using the positioning data elements which are constantly exchanged through CAMs. When the 
considered vehicle detects that another vehicle is entering its virtual safety shield, it will have to monitor the respective 
relative positions and velocities of this vehicle more carefully: if several vehicles are in its virtual safety shield, it will 
have to do the same thing for all of them. While monitoring the trajectories of other vehicles the following checks are 
supposed to be made: 

Is the traffic velocity greater than a certain value, e.g. 20 km/h? If not it may be considered that the virtual 
safety shield is not necessary as a collision should not have a severe impact on vehicles' occupants. 

Are the vehicles moving on the same road in the same direction? If yes are they longitudinally aligned? 

Are the vehicles moving on the same road in the opposite direction? If yes are they longitudinally aligned? 

If not being on the same road, will the vehicles' trajectories join at an intersection? 

Are the vehicles reducing their distances? 
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In the case where some of the previous conditions are met, e.g. the vehicles are longitudinally aligned and are reducing 
their distances and the traffic velocity is greater than 20 km/h, it can be deduced that the two vehicles are in a critical 
safety situation. At that time, a collision avoidance application is expected to enter its watch state and carefully observe 
any variation of the two vehicles trajectories. This means that in this watch state, any evolution of the vehicles 
trajectories, e.g. change of direction of one of the two vehicles or a deceleration, is supposed to be reported in real time 
(in less than 300 ms) to the other. A warning will be only issued to the driver at the last time to avoid the collision. The 
application waits to the last time to avoid sending a false positive warning to the driver in case of a sudden change of 
direction of one of the two considered vehicle eliminating the risk of collision. 

The minimum time required for the triggering of a driver warning is provided by the following equation: 

• DWTmin will be when TTC = MLT + MDRT + MAT + Margin. 

• MLT is the Maximum Latency Time (end to end latency time: For performance Class A less than 300 ms) 
required to obtain the last relevant data element values (age of the data) from a remote vehicle. 

• MDRT is the maximum driver reaction time which can be estimated in worst case to 2 s. However, the MDRT 
can be better estimated if the knowledge of the driver capabilities/current state is more detailed, e.g. vigilance 
state. 

• The Margin takes possible positioning errors and processing time into account. 

• MAT takes the deceleration capacities of the vehicle into account and approximates the driver behaviour 
(braking force). 

In this equation, the MAT is related to the deceleration capabilities of the two vehicles but also to other variables such 
as vehicle mass, the driver braking behaviour and the road state, e.g. adhesion. Consequently the evaluation of the MAT 
is completely under the responsibility of the OEM which is supplying the subject vehicle. 

This DWTmin can directly allow the calculation of the time left before a possible collision (used to determine the limits 
of the safety shield). 

When in a critical safety situation, the CAM interval can be reduced and the pseudonym change inhibited in order to 
avoid disturbing the watching process. The watching process is relying as fast as possible the most recent data elements 
transmitted by the other vehicles which are in this critical safety situation. 
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Annex F (informative): 

CAIVIs interval adjustment based on critical safety situation 

Several approaches are possible to adjust dynamically the CAMs interval: 

1) Adjustment from the CAM basic service itself based on originating (ego) Vehicle ITS-S perception of its 
highly dynamic data evolutions as specified in [ 1 ] . 

2) Adjustment from the local road safety applications based on their overall perception of the criticality of the 
traffic safety situation. 

However, the first solution does not seem to be convenient in some particular critical traffic safety situations such as the 
one involving a vehicle moving slowly (stopped) without significant dynamic evolutions but which however requires a 
decreasing of its CAMs interval when being in some critical traffic safety situation with one of its neighbours. Indeed 
the CAMs and DENMs are mainly necessary for the other ITS-S to adjust their behaviour according to the originating 
one. 

Moreover, the setting-up of the current conditions for decreasing the CAMs intervals are arbitrary and the repetition of 
the CAMs at low intervals is difficult to fix as being related to the quality and state (congested or not) of the used access 
network). 

The second solution would be more meaningful as it respects really the main cooperation principle existing between 
cooperative ITS-S. In this solution, the originating ITS-S safety application is detecting a critical traffic safety situation 
(through the permanent monitoring of the line of sight time distance with its neighbours and the relative velocities of 
surrounding vehicles) and then is able to request an adjustment of the CAMs interval when leaving its idle state 
(transiting to priority level "1" or "0" for ITS-S conforming to performance class A). The CAMs interval is expected to 
remain then at its lowest value (50 ms or 100 ms) as long as the application is not returned in an idle state corresponding 
to a priority level "2". 

Some other solutions not yet specified could also be based on the generalized usage of DENMs to signal critical traffic 
safety situations. 
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Annex G (informative): 
eCall backup concept 



If the eCall service cannot be achieved either because the vehicle is not equipped or the main media (cell network) is 
not locally accessible, it is possible that another Vehicle ITS-S backups the service using the main media being 
available at its level. 

This backup procedure has been developed and demonstrated in the course of the European project GST (Global 
System for Telematics). 

Initially proposed protocol: 

• When a "post crash warning" is triggered according to one eCall triggering condition, the "post crash warning" 
DENM is expected to be immediately transmitted. Normally, the originating ITS-S initiates an eCall in 
parallel. If this is not possible, the originating ITS-S may update its transmitted DENMs with a new "cause 
extension" indicating that an "eCall backup" is requested to an eCall equipped ITS-S being in the relevance 
area. 

• When DENMs requesting an eCall backup are transmitted, they include the standard MSD [4] of the 
originating ITS-S being in accident. 

• Upon reception of an eCall backup, an eCall equipped ITS-S may initiate a manual eCall after an acceptation 
of its driver, joining the received MSD. The manual eCall is necessary for the contacted PSAP to be able to 
call back the driver of the eCall backuping vehicle which has been accepting it. 

• Once the eCall has been successfully started, the backuping ITS-S transmits a "negate DENM" to stop the 
eCall backup process. This negate DENM is expected to be received by all ITS-S being in the relevance area 
including the originating ITS-S which may suppress its eCall backup request (cause extension and MSD) in 
further DENMs. 

• The backuping vehicle is expected to use the standard eCall protocol. 
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